How keypresses/releases are handled:

1) RFBView receives keyDown and keyUp messages and passes them on to
   its delegate (RFBConnection)

2) RFBConnection receives the messages in processKey:pressed: and extracts the
   keyCode which is hardware dependend and the unicode character.
   The unicode character, the keyCode and the modifiers are then passed
   on to the class KeyCodeConverter.

3) registerUnichar:forCode:modifiers: of KeyCodeConverter maps each keyCode
   to a unicode character and saves that information to a hash map and 
   eventually to a file in the .AppInfo directory (~/.AppInfo/VNCViewer/AutoKeyCodes).
   The mapping is created when a key is pressed the first time WITHOUT any
   modifier. This is so because a modifier may already result in a mapping
   to another unicode.
   An exception is the shift key. Each keycode is mapped once with and
   once without the shift key pressed.
   
4) If the mapping for the keyCode is not known (because the key has not
   been pressed without any modifier anytime before) a message box is
   displayed in the RFBView telling the user that he/she should press
   the key on its own so that the viewer can learn the keycode.
   This message box is only displayed for keyrelease events.
   If the controlkey is active, the unicode character is nevertheless
   changed into a control-A, control-B and so on.

5) If the mapping for the keyCode is known, KeyCodeConverter is called
   again to map the keyCode to a unicode.
   This has the effect, that any mapping activated on the local keyboard
   (via modifiers) is ignored and only the mapping of the server is
   used.

6) If UMLAUTE is defined, a hack is inserted at this point. The hack
   enables the usage of the german umlaut keys to be accessed even when
   using a us keyboard layout. The keycodes can be generated by pressing
   Alt-u and then one of a, o, u, A, O, U or s.

7) The resulting unicode character and the modifiers are then sent to
   sendKey:pressed: where the unicode characters from 0 to 255 and from
   0xf700 to 0xf7ff are mapped into X keycodes via two tables. The
   resulting keycode is sent to the server.

8) Special keys handled in sendModifier:
   a) The modifier keys of the local keyboard are mapped to server
	  modifiers via the active profile.
   b) F1 which is the help key in OpenStep is mapped in sendModifiers:
   
9) Buttonemulation
   a) With a two button mouse, the 3rd button is emulated by pressing the
	  two buttons within a configurable time span.
   b) With a single button mouse the 2nd and 3rd button can be emulated
      by pressing and releasing the Shift or the Control key and then
	  using the mouse button.
	  The cursor changes shape to indicate which button is currently
	  emulated.

10) Pros and cons of this scheme
	While it is nice to have the viewer learn your keyboard layout while
	you are typing away it is a drawback that it does not change the
	keyboard mapping if you decide to change your keyboard layout e.g.
	from US to German. This could be handled by changing KeyCodeConverter
	(Different Instances which handle the different keyboard layouts).
	The message boxes drawn in the RFBView whenever a keycode is unknown
	are not very meaningfull to most users and should be replaced/removed.

11) Command Key
	The OpenStep AppKit does not send a release message for the command
	key if the shortcut is defined. Thus all shortcuts except Command-Q are
	disabled in the viewer.
	
